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1. Abstract 


This document describes requirements for the provisioning of "roaming 
capability" for dialup Internet users. "Roaming capability" is 
defined as the ability to use multiple Internet service providers 
(ISPs), while maintaining a formal, customer-vendor relationship with 
only one. 


2. Introduction 


Operational roaming services are currently providing worldwide 
roaming capabilities, and these services continue to grow in 
popularity [1]. Interested parties have included: 


Regional Internet Service Providers (ISPs) operating within a 
particular state or province, looking to combine their efforts 
with those of other regional providers to offer services over a 
wider area. 


National ISPs wishing to combine their operations with those of 
one or more ISPs in another nation to provide greater coverage in 
a group of countries or on a continent. 


Businesses desiring to offer their employees a comprehensive 
package of dialup services on a global basis. Those services can 
include Internet access as well as secure access to corporate 
intranets via a Virtual Private Network (VPN). 
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This document provides an architectural framework for the 
provisioning of roaming capabilities, as well as describing the 
requirements that must be met by elements of the architecture. 


2.1. Requirements language 


In this document, the key words "MAY", "MUST, "MUST NOT", "optional", 
"recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as 
described in [4]. 


Please note that the requirements specified in this document are to 
be used in evaluating protocol submissions. As such, the 
requirements language refers to capabilities of these protocols; the 
protocol documents will specify whether these features are required, 
recommended, or optional for use in roaming. For example, requiring 
that a protocol support confidentiality is NOT the same thing as 
requiring that all protocol traffic be encrypted. 


A protocol submission is not compliant if it fails to satisfy one or 
more of the must or must not requirements for the capabilities that 
it implements. A protocol submission that satisfies all the must, 
must not, should and should not requirements for its capabilities is 
said to be "unconditionally compliant"; one that satisfies all the 
must and must not requirements but not all the should or should not 
requirements for its protocols is said to be "conditionally 
compliant." 


2.2. Terminology 
This document frequently uses the following terms: 


phone book 
This is a database or document containing data pertaining to 
dialup access, including phone numbers and any associated 
attributes. 


phone book server 
This is a server that maintains the latest version of the phone 
book. Clients communicate with phone book servers in order to 
keep their phone books up to date. 


Network Access Server 
The Network Access Server (NAS) is the device that clients dial in 


order to get access to the network. 
Authentication server 


This is a server which provides for authentication/authorization 
within the roaming architecture. 
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Accounting server 
This is a server which provides for accounting within the roaming 
architecture. 


Authentication proxy 
Authentication proxies may be deployed within the roaming 
architecture for several purposes, including authentication 
forwarding, policy implementation, shared secret management, and 
attribute editing. To the NAS, the authentication proxy appears 
to act as an authentication server; to the authentication server, 
the proxy appears to act as an authentication client. 


Accounting proxy 
Accounting proxies may be deployed within the roaming architecture 
for several purposes, including accounting forwarding, reliability 
improvement, auditing, and "pseudo-transactional" capability. To 
the NAS, the accounting proxy appears to act as an accounting 
server; to the accounting server, the proxy appears to act as an 
accounting client. 


Network Access Identifier 
In order to provide for the routing of authentication and 
accounting packets, user name MAY contain structure. This 
structure provides a means by which the authentication or 
accounting proxies will locate the authentication or accounting 
server that is to receive the request. 


3. Architectural framework 
The roaming architecture consists of three major subsystems: 


Phone book Subsystem 
Authentication Subsystem 
Accounting Subsystem 


The phone book subsystem is concerned with the maintenance and 
updating of the user phone book. The phone book provides the user 
with information on the location and phone numbers of Points of 
Presence (POPs) that are roaming enabled. The function of the 
authentication subsystem is to provide authorized users with access 
to the POPs in the phonebook, and to deny access to unauthorized 
users. The goal of the accounting subsystem is to provide 
information on the resources utilized during the user’s session. 


3.1. Phone Book Subsystem 


The phone book subsystem provides for the following: 
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Phone number presentation 
Phone number exchange 
Phone book compilation 
Phone book update 


Phone number presentation 
Phone number presentation involves the display of available phone 
numbers to the user, and culminates in the choosing of a number. 
Since the user interface and sequence of events involved in phone 
number presentation is a function of the connection management 
software being used, it is likely that individual vendors will 
take different approaches to the problem. These differences can 
include variances in the format of the client phone books, varying 


approaches to presentation, etc. There is no inherent problem 
with this. As a result, phone number presentation need not be 
standardized. 


Phone number exchange 
Phone number exchange involves propagation of phone number changes 
between providers in a roaming association. Current roaming 
implementations do not provide for complete automation of the 
phone number exchange process [1]. As a result, phone number 
exchange need not be standardized at this time. 


Phone book compilation 
Once an ISP’s phone book server has received its updates it needs 
to compile a new phone book and propagate this phone book to all 
the phone book servers operated by that ISP. Given that the 
compilation process does not affect protocol interoperability, it 
need not be standardized. 


Phone book update 
Once the phone book is compiled, it needs to be propagated to 
users. Standardization of the phone book update process allows 
for providers to update user phone books, independent of their 
client software or operating system. 


3.2. Authentication Subsystem 
The authentication subsystem provides for the following: 
Connection management 
Authentication 
NAS Configuration/Authorization 


Address Assignment/Routing 
Security 
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Connection management 
In order to be able to use the POPs of the local provider, it is 
first necessary to bring up a connection. 


Identification 
Authentication consists of two parts: the claim of identity (or 
identification) and the proof of the claim (or verification). As 


part of the authentication process, users identify themselves to 
the Network Access Server (NAS) in a manner that allows the 
authentication request to be routed its home destination. 


Authentication 
Authentication is typically required prior to allowing access to 
the network. CHAP [8] and PAP [9] are the two authentication 
protocols most commonly used within the PPP [10] framework today. 
Some groups of users are requiring different forms of proof of 
identity (e.g., token or smart cards, Kerberos credentials, etc.) 
for special purposes (such as acquiring access to corporate 
intranets). The Extensible Authentication Protocol (EAP) [7] was 
created in order to provide a general mechanism for support of 
these methods. 


NAS configuration/authorization 
In order to set up the session, authorization parameters need to 


be sent to from the home authentication server to the local ISP’s 
NAS. 


Address assignment/routing 
If it is desired that the user be able to communicate with the 
rest of the Internet, then the session will be assigned a routable 
IP address by the NAS. 


Security 
In the process of authenticating and authorizing the user session, 
it may be desirable to provide protection against a variety of 
security threats. 


3.3. Accounting Subsystem 


The function of the accounting subsystem is to enable the 
participants in the roaming consortium to keep track of what 
resources are used during a session. Relevant information includes 
how long the user was connected to the service, connection speed, 
port type, etc. 
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4. Roaming Requirements 
4.1. Phonebook requirements 
4.1.1. Phone book update protocol 


Portability 

The update protocol MUST allow for updating of clients on a range of 
platforms and operating systems. Therefore the update mechanism MUST 
NOT impose any operating system-specific requirements. 


Authentication 

The client MUST be able to determine the authenticity of the server 
sending the phone book update. The server MAY also be able to 
authenticate the client. 


Versioning 
The update protocol MUST provide for updating of the phone book from 
an arbitrary previous version to the latest available version. 


Integrity Checking 

The client MUST be able to determine the integrity of the received 
update before applying it, and MUST be able to determine the 
integrity of the newly produced phone book after updating it. 


Light weight transfers 
Since the client may be a low-end machine or internet appliance, the 
update protocol MUST be lightweight. 


Language support 

The phone book update mechanism MUST support the ability to request 
that the phone book be transmitted in a particular language and 
character set. For example, if the customer has a Russian language 
software package, then the propagation and update protocols MUST 
provide a mechanism for the user to request a Russian language phone 
book. 


4.1.2. Phone book format 


Phone number attributes 

The phone book format MUST support phone number attributes commonly 
used by Internet service providers. These attributes are required in 
order to provide users with information on the capabilities of the 
available phone numbers. 


Provider attributes 


In addition to providing information relating to a given phone 
number, the phone book MUST provide information on the individual 
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roaming consortium members. These attributes are required in order 
to provide users with information about the individual providers in 
the roaming consortium. 


Service attributes 

In addition to providing information relating to a given phone 
number, and service provider, the phone book MUST provide information 
relevant to configuration of the service. These attributes are 
necessary to provide the client with information relating to the 
operation of the service. 


Extensibility 

Since it will frequently be necessary to add phone book attributes, 
the phone book format MUST support the addition of phone number, 
provider and service attributes without modification to the update 
protocol. Registration of new phone book attributes will be handled 
by IANA. The attribute space MUST be sufficiently large to 
accomodate growth. 


Compactness 

Since phone book will typically be frequently updated, the phone book 
format MUST be compact so as to minimize the bandwidth used in 
updating it. 


4.2. Authentication requirements 
4.2.1. Connection Management 


Given the current popularity and near ubiquity of PPP, a roaming 
standard MUST provide support for PPP and IP. A roaming standard MAY 
provide support for other framing protocols such as SLIP. However, 
SLIP support is expected to prove difficult since SLIP does not 
support negotiation of connection parameters and lacks support for 
protocols other than IP. 


A roaming standard MAY provide support for non-IP protocols (e.g., 
IPX or AppleTalk) since these may be useful for the provision of 
corporate intranet access via the Internet. Since it is intended 
that the client will begin PPP negotiation immediately on connection, 
support for scripting SHOULD NOT be part of a roaming standard. 


4.2.2. Identification 


A roaming standard MUST provide a standardized format for the userID 
and realm presented to the NAS. 
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4.2.3. Verification of Identity 


Authentication types 
A roaming standard MUST support CHAP, and SHOULD support EAP. Due 
to security concerns, PAP authentication SHOULD NOT be supported. 
A possible exception is where PAP is used to support a one time 
password or token. 


Scalability 
A roaming standard, once available, is likely to be widely 
deployed on the Internet. A roaming standard MUST therefore 
provide sufficient scalability to allow for the formation of 
roaming associations with thousands of ISP members. 


RADIUS Support 
Given the current popularity and near ubiquity of RADIUS [2,3] as 
an authentication, authorization and accounting solution, a 
roaming standard MUST be able to incorporate RADIUS-enabled 
devices within the roaming architecture. It is expected that this 
will be accomplished by development of gateways between RADIUS and 
the roaming standard authentication, authorization, and accounting 


protocol. 
4.2.4. NAS Configuration/Authorization 


In order to ensure compatibility with the NAS or the local network, 
authentication/authorization proxies often will add, delete, or 
modify attributes returned by the home authentication server. In 
addition, an authentication proxy will often carry out resource 
management and policy functions. As a result, a roaming standard 
MUST support the ability of proxies to perform attribute editing and 
implement policy. 


4.2.5. Address assignment/routing 


A roaming standard MUST support dynamic address assignment. Static 
address assignment MAY be supported, most likely via layer 2 or layer 
3 tunneling. 


Layer 2 tunneling protocols 
Layer-2 tunneling protocols, such as PPTP, L2F, or L2TP, hold 
great promise for the implementation of Virtual Private Networks 
as a means for inexpensive access to remote networks. Therefore 
proxy implementations MUST NOT preclude use of layer 2 tunneling. 


Layer 3 tunneling protocols 
Layer-3 tunneling protocols as embodied in Mobile IP [5], hold 
great promise for providing "live", transparent mobility on the 
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part of mobile nodes on the Internet. Therefore, a roaming 
standard MUST NOT preclude the provisioning of Mobile IP Foreign 
Agents or other Mobile IP functionality on the part of service 
providers. 


6. Security 


Security analysis 
A roaming standard MUST include a thorough security analysis, 
including a description of security threats and countermeasures. 
This includes specification of mechanisms for fraud prevention and 


detection. 


Hop by hop security 
A roaming standard MUST provide for hop-by-hop integrity 
protection and confidentiality. This MAY be accomplished through 
support of network layer security (IPSEC) [6]. 


End-to-end security 
As policy implementation and attribute editing are common in 
roaming systems, proxies may need to modify packets in transit 
between a local NAS and the home server. In order to permit 
authorized modifications while at the same time guarding against 
attacks by rogue proxies, it is necessary for a roaming standard 
to support data object security. As a result, a roaming standard 
MUST provide end-to-end confidentiality and integrity protection 
on an attribute-by-attribute basis. However, non-repudiation is 
NOT a requirement for a roaming standard. 


Accounting requirements 


Real-time accounting 
In today’s roaming implementations, real-time accounting is a 
practical necessity in order to support fraud detection and risk 
management. As a result, a roaming standard MUST provide support 
for real-time accounting. 


Accounting record formats 
Today there is no proposed standard for NAS accounting, and there 
is wide variation in the protocols used by providers to 
communicate accounting information within their own organizations. 
Therefore, a roaming standard MUST prescribe a standardized format 
for accounting records. For the sake of efficiency, the record 
format MUST be compact. 


Extensibility 
A standard accounting record format MUST be able to encode metrics 
commonly used to determine the user’s bill. Since these metrics 
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change over time, the accounting record format MUST be extensible 
so as to be able to add future metrics as they come along. The 
record format MUST support both standard metrics as well as 
vendor-specific metrics. 
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This document, being a requirements document, does not have any 
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evaluated using this document are mainly described in section 5.2. 
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9. Full Copyright Statement 
Copyright (C) The Internet Society (1999). All Rights Reserved. 


This document and translations of it may be copied and furnished to 
others, and derivative works that comment on or otherwise explain it 
or assist in its implementation may be prepared, copied, published 
and distributed, in whole or in part, without restriction of any 
kind, provided that the above copyright notice and this paragraph are 
included on all such copies and derivative works. However, this 
document itself may not be modified in any way, such as by removing 
the copyright notice or references to the Internet Society or other 
Internet organizations, except as needed for the purpose of 
developing Internet standards in which case the procedures for 
copyrights defined in the Internet Standards process must be 
followed, or as required to translate it into languages other than 
English. 


The limited permissions granted above are perpetual and will not be 
revoked by the Internet Society or its successors or assigns. 


This document and the information contained herein is provided on an 
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 


Aboba & Zorn Informational [Page 12] 


